Principles

XTagManager customization is based on a set of global functions which can be declared or not. This is the Global Customizer.
By default, XTag Configurator generates a mapping of these functions into an Object Model allowing Single or Multiple Level(s) of Inheritance. This is the Class Customizer.
Both approaches and all their combinations can address efficiently the most complex websites specificities, all kind of technologies -present or future-, but also any Web Analytics platforms evolution.
This tutorial explains how to initiate and manage your Customization code, based on the Class Customizer generated by XTag Configurator with Customisation JS command.

Steps

1. Choose your Configuration Model

Two models can be used: the simpler Single Level of Inheritance (SLI), or the more sophisticated Multiple Levels of Inheritance (MLI).
Basically, if your website doesn't use Level 2 classification, there's no doubt: you can use the simpler one.
If it does, all depends on your website structure:

If it is made of several independent applications with different requirements, and that you can't use a different Configuration for each of them because of technical limitations, the MLI is the best option.
In all other cases, start by SLI, it needs no effort to be initiated, and could be converted later in MLI if needed, from instructions below.

By default, XTag Configurator generates a SLI Customizer when Perimeters tab is empty, and a MLI when it is populated.

2. Design your Class Model

If you use a SLI Customizer, only CStatBase is used, and it is already created, so you can jump to step 4.
If you use MLI, think about your class model, by following common design principles.
In the following examples, MLI is illustrated with a base class CStatBase, from which are derived two classes: CStatProduct and CStatRange.

classDiagram class CStatBase { -name +getName() +setPathName() } CStatApp <|-- CStatBase CStatBase <|-- CStatProduct CStatBase <|-- CStatRange

3. Create the Factory

CStatApp.factory must be instantiated, depending on the Configuration Model selected.

Single Level of Inheritance

Following code has been generated, you don't need to modify it:

CStatApp.factory=function(name)
{
   if (!CStatApp.base){new CStatBase();}
   CStatApp.extend=CStatApp.extend||CStatApp.base;
}

Multiple Levels of Inheritance

You need to define an application name property.

If you already have a MLI model, it has already been generated.

If you are migrating from SLI to MLI, just add the lines below in CStatBase class:

    this.name='';
    this.getName=function(){return this.name;};

You also have to define the way each application name is identified (from one particular folder, from a cookie, etc..).

If you already have a MLI model, the name handler has already been generated.

If you are migrating from SLI to MLI, copy the lines below in CStatBase class.
In all cases, you need to write/adjust this method content in order to meet your naming logic:

    this.setPathName=function(p)
    {
        // Use third folder (after /country/language) as application name, "home" by default
        var ap=p.split('/');
        this.name=(ap.length>3 && ap[3])?ap[3]:'home';
    };

Then, define each class identified in your model.

If you already have a MLI model, CStatPattern has been generated as example: rename it CStatProduct, then copy it to make CStatRange.

If you are migrating from SLI to MLI, copy the lines below after CStatBase class:

function CStatProduct()
{
    CStatBase.call(this);
    var _Super={} ;// Add one underscore per level of inheritance.
    
    //...
}
function CStatRange()
{
    CStatBase.call(this);
    var _Super={} ;// Add one underscore per level of inheritance.
    
    //...
}

Finally, the generated factory must be adjusted to create the right class instance depending on defined name.

If you already have a MLI model, the proper structure is already created, just adapt the switch / case logic.

If you are migrating from SLI to MLI, replace generated factory by the one below:

CStatApp.factory=function(name)
{
    if (!CStatApp.base)
    {
        new CStatBase();
    }
    else if (!CStatApp.extend)
    {
        switch (name)
        {
        case 'product':
            new CStatProduct(); break;
        case 'range':
            new CStatRange(); break;         
        default:
            // Unknown names use the base class
            CStatApp.extend=CStatApp.base;
        }
    }
};

4. Implement your Customization code

Not all methods are overridden in the generated Customization JS, only those corresponding to the Analysis selected at generation time.
However, it is easy to complete it later:

Reach the method you need from its link below,
Copy the snippet proposed as example and paste it in your class.
Adapt the snippet to meet your requirements. Take care to adapt also the "Super" call if you are in a Multi Level of Inheritance, depending on the base behavior you want to call.

Page Tags Control

Visitor Identification Control

Clicks & Events Tags Control

Sales Control

Internal Search Engine Control

Videos Control

5. Override Class Customizer

For some reasons, you can be annoyed by such default Class Customizer mapping, and want to unify some behaviours in your organization without the constraining inheritance of a mother class common to all.

In this case, create your own customizations for the entry points on which you want to take back control, and include this set of customizers just after the object mapping.

Create mycompany_custom.js in your Library folder:

function getCustomExtraLeaf()
{
    return '::undefined';
}
function getCustomExtraChapter()
{
    return '|';
}

Then, modify your Customization file header to include it after the Class Customizer:

/* Global Customizer mapping to Class Customizer */
/*#include stat_object.js*/

/* Customizers overrides */
/*#include mycompany_custom.js*/
//...